home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19960715-19961006 / 000172_news@columbia.edu _Mon Aug 12 13:10:31 1996.msg < prev    next >
Internet Message Format  |  2020-01-01  |  4KB
  1. Return-Path: news@columbia.edu
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30]) by watsun.cc.columbia.edu (8.7.5/8.7.3) with ESMTP id NAA07931 for <kermit.misc@watsun.cc.columbia.edu>; Mon, 12 Aug 1996 13:10:27 -0400 (EDT)
  3. Received: (from news@localhost) by newsmaster.cc.columbia.edu (8.7.5/8.7.3) id NAA19419 for kermit.misc@watsun; Mon, 12 Aug 1996 13:10:27 -0400 (EDT)
  4. Path: news.columbia.edu!sol.ctr.columbia.edu!spool.mu.edu!newshub.tc.umn.edu!newsfeed.orst.edu!gateway.sequent.com!uunet!in3.uu.net!cs.utexas.edu!news.cs.utah.edu!cc.usu.edu!jrd
  5. From: jrd@cc.usu.edu (Joe Doupnik)
  6. Newsgroups: comp.protocols.kermit.misc
  7. Subject: Re: MS-KERMIT 3.14 server "REMOTE DELETE" problem
  8. Message-ID: <1996Aug12.084424.83830@cc.usu.edu>
  9. Date: 12 Aug 96 08:44:24 MDT
  10. References: <B.A.MCCAULEY.96Aug8114643@wcl-l.bham.ac.uk> <B.A.MCCAULEY.96Aug9173244@wcl-l.bham.ac.uk>
  11. Organization: Utah State University
  12. Lines: 64
  13.  
  14. In article <B.A.MCCAULEY.96Aug9173244@wcl-l.bham.ac.uk>, B.A.McCauley@bham.ac.uk writes:
  15. > In article <4ucor3$4j5@apakabar.cc.columbia.edu>,
  16. >  fdc@watsun.cc.columbia.edu (Frank da Cruz) writes:
  17. >>In article <B.A.MCCAULEY.96Aug8114643@wcl-l.bham.ac.uk>,
  18. >> <B.A.McCauley@bham.ac.uk> wrote:
  19. >>: I have a PC running MS-KERMIT 3.14 server to provide access to a
  20. >>: filesystem.  The application talking to this server is a home-grown
  21. >>: implementation of the Kermit protocols.  When the application attempts
  22. >>: to delete a file using the "REMOTE DELETE" command I get a problem if
  23. >>: any of the components of the filename start with a digit.  I assume
  24. >>: this is because the backslash-digit sequence is being interpreted as a
  25. >>: control character.
  26. >>: 
  27. >>Perhaps, but by whom?
  28. > 
  29. > Well it's not my software and I very much doubt it's COMMAND.COM this
  30. > leaves MS-KERMIT as the prime suspect.
  31. > 
  32. >>When sending a server command from C-Kermit or MS-DOS Kermit to a Kermit
  33. >>server that runs on a DOS-like file system, you have to double the
  34. >>backslashes in your commands, to force the *command interpreter* to take
  35. >>the backslash literally.
  36. > 
  37. > Oh no you don't!  The *DOS* command interpreter does not treat
  38. > backlashes as special.  Unix ones do.  It still seems odd to me that
  39. > using the "*GENERIC* delete" command that the protocol would allow me
  40. > to be affected by idiosyncracies of the host operating system's
  41. > command interpreter.
  42. > 
  43. >>In the Kermit *protocol*, there is nothing special about backslashes.
  44. >>Here are the packets from a successful REMOTE DELETE operation:
  45. >>
  46. >>  ^A1 GE,c:\tmp\123.xT
  47. >>  ^A3 Ydel c:\tmp\123.xL
  48. >>
  49. >>As you can see, the backslashes are backslashes. 
  50. > 
  51. > Here are the packets from an unsuccessful REMOTE DELETE operation:
  52. > 
  53. >   ^A- GE(T:\123.xG
  54. >   ^A, Ydel T:{.xK
  55. > 
  56. > As you can see, the backslashes are not backslashes once MS-KERMIT has
  57. > had it's way with them.
  58. > 
  59. > Assuming the packets you showed me are for real, you are telling me by
  60. > implication that I have found a bug in MS-KERMIT 3.14pl0 but that it's
  61. > already fixed in the version you are using.
  62. > 
  63. > In case you are wondering why I'm using pl0 rather than the latest
  64. > patch level it's because I had some other problems with ARP in later
  65. > versions.  Indeed the problem appeared in exactly the patch level
  66. > where the release notes said that an ARP bug had been fixed.  In fact
  67. > I've still having ARP problems so I think I'll try upgrading again.
  68. > 
  69. > If the backslash bug is still in the later version I'll get back to you.
  70. -----------
  71.     It's not a bug, it's a feature, as they say. There is just so much
  72. overloading of syntax that can be dealt with in a general way. MSK 3.14 has
  73. definite limits on the syntax, MSK 3.15 has relaxed the limits about as far
  74. as possible, so please do try v3.15/beta. Since you are also writing code
  75. you might appreciate the difficulties creating a parser and workers for the
  76. syntax.
  77.     Joe D.